Fixed some flashing issues on STM32L0 #1330
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stm32l1_write_half_pages uses a local flash_loader_t that is never initialized. This results in stlink_flash_loader_run using uninitialized values for fl->buf_addr and fl->loader_addr when copying the buffer and initializing the source register and PC before running the core to execute the flashloader. Pass the flash_loader_t from stlink_flashloader_write through to stm32l1_write_half_pages and use that one instead of an uninitialized local structure.
STM32L0 chips use loader_code_stm32lx, but this flash loader is built for armv7-m and uses instructions that are unsupported on STM32L0 (which have Cortex M0+ cores implementing armv6-m). In particular, loader_code_stm32lx uses variants of add-immediate that do not update the condition flags ( `add r0, r0, stlink-org#4` ). These are 32bit instructions in armv7-m and are not available in armv6-m. Enable loader_code_stm32lx to run on both armv6-m and armv7-m by building for armv6-m, which requires changing the `add` instructions to `adds` instructions that do update condition flags (which is ok because the subs updates the condition flags again before the branch).
Nightwalker-87
approved these changes
Aug 27, 2023
|
Now we need to identify the related issues that are addressed by this fix. |
Nightwalker-87
changed the title
Ant-ON
approved these changes
Aug 28, 2023
|
@Nightwalker-87 I think this most likely should fix #1203, #1289, #1253 |
Nightwalker-87
added
status/resolved
component/stlink-lib
and removed
needs/investigation
needs/testing
labels
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
While trying to use st-link to flash a STM32L051 on a custom board, the flash loader fails in
stm32l1_write_half_pages, and the fallback path usually reports "Flash memory contains a non-erased value" (but still successfully writes the flash since the NOTZEROERR doesn't prevent the write on this category 3 device - 3.3.4 RM0377). Sost-flash writedoes write the flash but reports failure, andloadin gdb usingst-utilserver reportsError finishing flash operation.I found two issues in the flashing code:
stm32l1_write_half_pagescallsstlink_flash_loader_runwith a localflash_loader_tstruct that is never initialized, so the loader is run using uninitialized values for the loader code base address and the SRAM buffer addressloader_code_stm32lxis used for both STM32L0 devices with armv6-m cores and STM32L1 devices with armv7-m, but it usesaddinstructions that are only supported in armv7-m, so when loader code runs it writes one word to flash and then faults on theadd.With these issues fixed, flashing works without error on this device.
This is related to the various reported issues about failures flashing STM32Lx devices (e.g. in #681) and probably helps fix some of those, but I don't have other hardware to test on to confirm if this improves things on devices other than STM32L051. Based on the code history these 2 bugs seem to be introduced more recently than some of the early reported issues, so there may be some remaining issues too.
It seems like the current flashloader implementation in
stm32l1_write_half_pagesmaybe doesn't have much advantage over the fallback path usingstlink_write_mem32since both wait for flash programming to complete from the host system every halfpage, but these 2 commits make this path work for now on in my testing on STM32L051( in the future it can potentially be enhanced to poll on
FLASH_SR_BSYevery halfpage from the device instead of the host or removed if not useful)(Closes #681) (Closes #1203) (Closes #1225) (Closes #1253) (Closes #1289)